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Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
http://webapp.etsi.org/kev/quervform.asp . 
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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



rd , 



The present document is part of a TS-family covering the 3 Generation Partnership Project; Technical Specification 
Group Services and System Aspects; Telecommunication management; as identified below: 

32.391: "Delta Synchronization Integration Reference Point (IRP): Requirements". 

32.392: "Delta Synchronization Integration Reference Point (IRP); Information Service (IS)". 

32.396: "Delta Synchronization Integration Reference Point (IRP); Solution Set (SS) definitions". 

The Itf-N interface is built up by a number of IRPs and a related Name Convention, which realise the functional 
capabilities over this interface. The basic structure of the IRPs is defined in 3GPP TS 32.101 [1] and 
3GPPTS 32.102 [2]. 

IRPManagers (typically Network Management Systems) and IRP Agents (typically EMs or NEs) synchronize their data 
concerning alarms or configuration data. In certain scenarios this synchronization is lost or not done. This IRP provides 
functionality to significantly reduce the amount of data which needs to be transferred in order to re-establish 
synchronization. 
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Scope 



The purpose of Delta Synchronization IRP is to define an interface through which an IRPManager can request only 
those data which changed (i.e. changed, were created or deleted) from a synchronization point onwards. 

The present document contains the Requirements of Delta Synchronization IRP. It defines, for the purpose of Delta 
Synchronization, the basic requirements to be fulfilled on Itf-N. 



References 



The following documents contain provisions that, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[2] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[3] 3GPP TS 32.302: "Telecommunication management; Configuration Management (CM); 

Notification Integration Reference Point (IRP); Information Service (IS)". 

[4] 3GPP TS 32.342: "Telecommunication management; File Transfer (FT); Integration Reference 

Point (IRP); Information Service (IS)". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

changed instance / alarm: it refers to a managed object instance or an alarm that has changed during a period defined 
two time based references 

A managed object instance / alarm is considered changed if: 

a) It is present at the beginning of the period and absent at the end of the period; or 

b) It is absent at the beginning of the period and present at the end of the period; or 

c) At least one of its attribute / parameter values is different at the beginning and at the end of the period. 

CM data: data which can be managed by CM (no matter if basic or bulk CM) 

delta synchronization: state of MIB is the totality of states of all managed object instances in that MIB 
State of MIB can be changed. AlarmList content can be changed. Delta synchronization refers to a process where the 
IRPManager's view of the MIB state or the AlarmList content at Tl (sometimes referred to as the beginning of the Delta 
Synchronization period) can be updated to that at T2 (sometimes referred to as the end of the Delta Synchronization 
period) by receiving and processing only those data involving changed instances. 
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delta synchronization point: it refers to a point in time based on the clock used by the IRP Agent 
It relates to the Tl and T2 of the Delta Synchronization process. 

FM data: alarm data as it would be retrieved with operation getAlarmList 

full synchronization: it is a specialized Delta Synchronization process in that at Tl (beginning of the Delta 
Synchronization period), there is no managed object instance or the AlarmList content is empty 

IRP: See 3GPP TS 32.101 [1]. 

IRPAgent: See 3GPP TS 32.102 [2]. 

IRPManager: See 3GPP TS 32.102 [2]. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

CM Configuration Management 

EM Element Manager 

IRP Integration Reference Point 

IS Information Service (see 3GPP TS 32. 101 [1]) 

Itf-N Interface N 

MIB Management Information Base 

NE Network Element 

4 Requirements for Delta Synchronization between 

IRP IVIanager and IRP Agent 



4.1 Concept 



Delta Synchronization allows an IRPManager to request information about changes which took place since a specific 
point in time (synchronization point) and applies both to the alarm list and configuration data. This gives the 
IRPManager an efficient way to align his picture with the picture the IRPAgent has. 

4.1.1 Difference to full synchronization: 

"Full synchronization", provided in TS 32.60n and 32.1 1 1-n series by operations such as getMOAttributes and 
getAlarmList, on the other hand delivers - in the requested scope (and filter, if applied) - the complete data at that point 
in time when the IRPAgent prepares the response to such an operation request. 

For all cases when only a few data have changed, a "full synchronization" would deliver too many data and the 
potentially huge amount of data would have to be checked where changes took place. Delta synchronization can be 
beneficial in these cases. 

This benefit would be destroyed, if in responses to delta synchronization request the IRPAgent would deliver the same 
data as in full synchronization responses. Therefore this is not allowed (except in the trivial cases where the changed 
data is identical to the existing data). 

4. 1 .2 Difference to logging: 

A suitably administered log contains a history of the changes which took place, potentially also since the 
synchronization point. But many of these changes could refer to the same instances which e.g. changed several times or 
where changes were undone again. 

Delta synchronization tries to compress this information as far as possible to only one set of delta synchronization data 
per changed instance and not to report undone changes. Therefore it is not allowed to deliver the full change history 
since the synchronization point (except for those trivial cases when there were no "compressible" changes). 
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NOTE: Delta synchronization not necessarily has to be based on a log. For cases where changes take place which 
are not recorded in a log - e.g. because the changes do not result in a notification to be logged - using the 
log would fail to produce the correct delta synchronization data. 

4.2 General requirements 

4.2.1 Data which require delta synchronization: 
4.2.1.2 CM data 

4.2.1.2 FMdata 

4.2.2 Scenarios when delta synchronization can be required: 

4.2.2. 1 IRPManager recognizes that its data may not be up-to-date 

4.2.2.2 Interruption and re-establishment of the Manager- Agent communication (especially useful for 
interruptions when not a very big amount of data changed) 

4.2.2.3 IRP Agent does not generate CM-related notifications (notifyObjectCreation / notifyObjectDeletion / 
notifiyAttributeValueChange) 

4.2.2.4 IRPManager does not evaluate CM-related notifications (notifyObjectCreation / notifyObjectDeletion 
/ notifiyAttributeValueChange) 

4.2.2.5 IRPManager regularly synchronizes its data 

4.2.3 Time aspects 

4.2.3. 1 Time parameters in the context of the delta synchronization refer to the IRP Agent's time. 

4.3 Requirements for operations related to delta 
synchronization 

4.3. 1 The Itf-N shall allow an IRPManager to request delta synchronization data for the managed resources of the 
whole or optionally only a part of the network. 

4.3.2 The Itf-N shall allow an IRPManager to specify in its request if it wants delta synchronization data starting from 
a synchronization point in time or from the last synchronization (i.e. the last time the IRP Agent stored a section 
of the delta data). 

The IRP Agent may choose to only accept a request for delta data related to the IRP Agent's own 
synchronizationPoints 

4.3.3 The Itf-N should allow an IRPManager to request if it wants in delta synchronization responses - only the 
identification of the changed instances (concerning configuration or alarm status) or - the complete data 
(attributes/parameters) of the changed instances (including identification). This choice is not possible, if the delta 
data is delivered in files, not in the operation response. 

4.3.4 The IRP Agent shall indicate in its response to the delta synchronization request whether the delivered data is 
new, was modified or deleted since the last delta synchronization / last getAlarmList / last getMOattributes / 
synchronization point. 

4.3.4.1 If an instance is created and deleted again / an alarm is raised and cleared again and acknowledged, 
then both should not be reported, if the IRP Agent can fulfil the delta synchronization request exactly. 
If the IRP Agent delivers more data, then the deletion / alarm acknowledgement should be reported. 

4.3.4.2 If an attribute value / an alarm parameter changes several times and the end value is not equal to the 
start value, then only the last change shall be reported 

4.3.4.3 If an attribute value / an alarm parameter changes and returns to its start value, then either nothing 
shall be reported or the last value. It is only allowed to report a last value, which is equal to the start 
value, if a change took place in between. Start- and end synchronization point shall be indicated by the 
IRP Agent. (This requirement is valid within one operation response/file.) 
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4.3.5 The Itf-N shall allow an IRPManager to request activation or deactivation of the delta synchronization 
functionality. 

4.3.6 The Itf-N shall allow an IRPManager to request a synchronizationPoint in the IRP Agent. The time for this 
synchronizationPoint is determined by the IRP Agent. 

4.3.7 The Itf-N shall allow an IRPManager to request to read the available synchronizationPoints. 

4.3.8 A change shall be reported in a delta synchronization response regardless whether the change was already been 
or will be reported by other means (e.g. by a notification). 

4.3.9 The agent may deliver more, but not less than the changed data since the delta synchronization point. The agent 
should try to keep the excess delta data as small as possible. In case of such excess data the IRP Agent has to 
specify the used synchronization point in its reply to the IRPManager. 

4.3.10 The IRP Agent may reject the delta synchronization request if too many data changed since the specified delta 
synchronization point. In case of such a rejection the IRP Agent has to specify the reason in its reply to the 
IRPManager. 

4.3. 11 The IRP Agent may reject the delta synchronization request with "last synchronization" as synchronization point, 
if the IRP Agent can not determine this last synchronization point. In case of such a rejection the IRP Agent shall 
specify the reason in its reply to the IRPManager. 

4.3.12 If the delta synchronization functionality is deactivated, then a notification indicating this shall be sent out by the 
IRPAgent. 

4.3.13 Optional requirement: The IRP Agent sends a notification when it establishes a new synchronizationPoint. 

4.3.14 The IRPAgent may deliver the delta data not directly, but via references to files. In this case the availability of 
the files shall be announced by a notifyFileReady (see [4] ). 
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